Environment: Exchange 2007 SP1 Update Rollup 10, Standalone install, all roles on one server. Server OS is Windows 2008 Standard. Outlook anywhere is setup on all clients. So I noticed today that the "Domain Users" AD group was a member of the Windows local "administrators" group on the Exchange Server. I thought thats odd and obviously not correct so I decided to remove the Domain Users group from the local admins due to security concerns. About 10 minutes after doing this I get a call from a user saying they are being prompted for credentials when opening Outlook. The prompt would not accept the users password and authentication could not be performed, the prompt would simply keep popping up. I tested Outlook on a test machine with a standard user account (not an admin account) and received the same prompt. I added the Domain Users group back to the local admin group on the Exchange Server and the issue is resolved, no more prompting users for credentials. So question: Is this normal? Does the user need to be an admin on the Exchange box thus requiring an all encomposing group such as "Domain Users" to be in the local admins group on the server Exchange resides on? THis doesnt sound right and I have found nothing so far as to why this would be set, but it does have to be configured (at least in my environment) in order to Outlook to connect. Outlook clients are configured to use Outlook anywhere even internally. Maybe this has something to do with it? Any suggestions or help is appreciated. Thanks!

Domain Users are definitely not supposed to be in the local Administrators group. Are Domain Users in the local Users group? If at some point it had gotten "moved", that could be your problem. dave

I would recommend to check your settings in IIS for the rpc virtual dir. Users need to locate the rpc proxy running on your exchange server which is basically a .dll (rpcproxy.dll) usually in the windows\system32\rpc\ folder, they access it through IIS (URL is something like https://server.yourdomain.com/rpc/rpcproxy.dll) Since that dll is located in system root folder, which only administrators have access to, that might be the issue. Please review the guide on how to setup Outlook Anywhere here http://technet.microsoft.com/en-us/library/bb123889(EXCHG.80).aspx and make sure all tasks listed there have been completed properly. I would start checking if users can reach the rpcproxy url when they are not in the local admin group. Please follow this link for that: http://technet.microsoft.com/en-us/library/bb124175(EXCHG.65).aspxVincenzo MCTS, MCTIP Server 2008 | MCTS Exchange 2010 | WatchGuard Firewall Security Professional

1. I would also update to the latest SP and RU unless you have a reason not to. 2. I would then check your IIS settings. 3. There is a know issue but I believe this was addressed in on of the RU and RU 10 definitly includes this.Sukh

This typically happens if your Exchange groups are not nested correctly from the default settings or the ntfs permissions have been changed from the default settings on the Exchange binaries. You typically see this behavior or another common one such as only admins being able to log into OWA. Couple things I would do: 1. Go to C:\Program Files\Microsoft\Exchange Server\ and sample several subdirectories permissions and verify that authenticated users is present and have read access. Each subdirectory doesn't have the same permission by default and you will not find any documention, so you need to sample any other good Exchange servers you have or build a sample one in the lab to compare against. 2. Re-run setup with prepareAD again setup /prepareAD Also the permissions may not necessarily lie within the binary files themselves but within the Exchange org partition in AD. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

yeah, You should run /PrepareAd to re-create the AD permission propelly. And then install Sp2 or SP3 on the Exchange servers, that will help you to use Diagnostic loggin on GUI mode. RegardsChinthaka Shameera | MCITP: EA | MCSE: M | http://howtoexchange.wordpress.com/

Hi MAC, Any update for your issue? Above gave some good suggestion. Please check them. Regards! Gavin TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

I have not had a chance I will start testing as other issues have arisen THanks all for the good info so far. I will of course report my results.

Domain Users is in the Local Users group.

"Since that dll is located in system root folder, which only administrators have access to, that might be the issue." The local user group (which Domain Users is a member of) does have read access to the rpcproxy.dll file. "Please review the guide on how to setup Outlook Anywhere here http://technet.microsoft.com/en-us/library/bb123889(EXCHG.80).aspx and make sure all tasks listed there have been completed properly." Everything looks good. "I would start checking if users can reach the rpcproxy url when they are not in the local admin group. Please follow this link for that: http://technet.microsoft.com/en-us/library/bb124175(EXCHG.65).aspx" OWA is being published through ISA 2006. Could not complete these steps via this link.

1. No reason not to and I do plan on going to SP3, but I'm sure this is a little envolved and not sure if I'll get to it soon. Also, I would like to correct these issues before the upgrade. 2. What settings in IIS can you suggest I check? thanks

1. Go to C:\Program Files\Microsoft\Exchange Server\ and sample several subdirectories permissions and verify that authenticated users is present and have read access. Each subdirectory doesn't have the same permission by default and you will not find any documention, so you need to sample any other good Exchange servers you have or build a sample one in the lab to compare against. Unfortuneately, I do not have another Exchange Server to compare against. Can anyone assit with this? However, looking at the permissions on the Exchange directory folders I find Authenticated Users with the following access rights: Bin (read access), ClientAccess (no Auth Users listed - no access), Exchange OAB (no Auth Users listed), Logging and Mailbox (not listed), Public (read access), Scripts, Setup, TransportRoles, UnifiedMessaging,Working (all of these Authenticated Users is not listed)

Hi Mac1234, I would suggest that you could build a test lab to confirm the configuration. Because there are much information, it is better to follow carefully, if you have a good test lab. Regards! Gavin TechNet Subscriber Support in forum If you have any feedback on our support, please contacttngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Tracked the issue down to no "Authenticated Users" read permission on the following folder: ..\ExchServer\ClientAccess\exchweb Test process: Created a test account, configured Outlook with test account on test machine. Removed test account from "Domain Users" AD group, problem occured in Outlook. Assigned read permissions to the ClientAccess folder just for this user and tested Outlook successfully. Removed top level read permissions to user then proceeded to add read permissions 1 by 1 to each subfolder (ClientAccess\...) that had NO Authenticated Users permissions. Added "Authenticated Users" to the folder that was found to fix the issue. Also found this link after the fact which does confirm the permissions on the problem folder. Link has at least the NTFS permissions for some Virtual DIrectory folders. Folder is EWS. http://busbar.blogspot.com/2010/05/exchange-20102007-virtual-directory_16.html So as to why the permissions were messed up in the first place? I'm not sure, but this looks like a case of "something isn't working so find a quick fix and go" But, who knows why the permissions were messed up in the first place. Maybe it was like this from initial install or maybe an Update did it. The person that installed Exchange is no longer here.